Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/015a/seemem.zip/SEEMEM.DOC

Text File | 1991-10-18 | 13KB | 230 lines

                                SEEMEM.EXE


          Author:             Tedrick A. Housh, Jr.
                              5811 West 85th Terrace
                              Overland Park, KS 66207


          Electronic Mail:    CompuServe 72466,212
                              GEnie      RHOUSH


     The objective of SEEMEM is to display information about the
     current use of MS-DOS memory by the operating system, and
     resident processes and data.

     It is designed to make full use of the new memory facilities
     provided by DOS version 5.0, and to provide information similar
     to the provided by the DOS utility MEM.  However, it provides
     this information even when DOS does not control Upper or Extended
     memory, and even when HIMEM.SYS and EMM386.EXE are not loaded,
     and recognizes UMB's created by other programs, such as
     Quarterdeck Software's QEMM386 (for 386 and higher) and QRAM (for
     286 cpu's with EMS version 4.00 hardware or Chips and
     Technologies Shadow Ram).  It works with these programs on all
     versions of DOS greater than 1, and on all CPU chips, 8088 and
     higher, although the memory detail displayed increases with
     increase in CPU version.

     SEEMEM was written in Turbo Pascal 6.00, as an exercise in the
     use of the Built-In Assembler (BASM).  In that connection, all
     necessary DOS functions were specifically coded in BASM, as were
     all functions which necessarily interface with the extended
     memory (XMS) driver provided by HIMEM.SYS, or its counterparts
     such as QEMM386.SYS, or QEXT.SYS, or EMM386.SYS or QEXT.SYS.
     This completely eliminates the need for the Turbo Pascal DOS
     unit, or a unit to interface with the XMS and UMB device drivers.
     All the low level functions necessary for this purpose are
     included directly in the SEEMEM.PAS file as BASM code, and the
     .PAS file is independent and completely self-supporting.

     The display output for SEEMEM is in three parts.  The first part,
     which may include several screen pages displays every memory
     control block (MCB) between Segment 0 and the top of conventional
     memory (Segment 9FFFh on a 640k machine), and also between the
     top of conventional memory and the start of the High Memory Area
     (HMA) if any, or the top of Upper Memory (Segment 0FFFFh).  For
     each MCB SEEMEM displays its segment address (in hex), its size
     (in both Kilobytes and bytes), the segment of its "owner," its
     type (e.g. Process or Environment), and its name (if
     determinable).

     The second part is a display of EMS (Expanded Memory) if
     applicable.  This displays the version number of the EMS device
     driver, the page frame segment, the total size of the installed
     EMS memory, the number of mapping register sets available,
     whether or not nonvolatile handles (will survive warm boot) are
     available, the number of DMA channels , the maximum number of EMS
     handles supported, the number of free handles, free pages, page
     size, and free memory, and for each handle in use, the handle
     number, the number of EMS pages, the page size, the memory used,
     and if available, the handle name.  This second part may occupy
     more than one screen page.

     The third part displays XMS information (if a driver is
     installed), including XMS version number, revision number, the
     XMM Control Vector in segment:offset form, total XMS free memory,
     and largest free XMS block.  With respect to the High Memory Area
     (HMA) SEEMEM shows whether the A20 line is currently enabled,
     whether HMA is implemented, whether the HMA is available for use.
     If the DOS version is 5.00 or greater SEEMEM also will say
     whether DOS is resident in the HMA (DOS=HIGH in config.sys), and,
     if so, how much of the HMA DOS has left available for additional
     buffers, etc.  SEEMEM also displays the location of DOS when it
     is located elsewhere (i.e. ROM or Conventional memory).

     The third part also displays information about Upper Memory
     Blocks (UMB's) if available:  whether UMB's are implemented,
     whether they are controlled by device driver or by DOS itself
     (with DOS 5.00 and higher), whether UMB's are linked to
     conventional memory (DOS 5.00) or are independent, and whether
     UMB's are implemented by DOS=UMB in CONFIG.SYS (DOS 5.00).

     Seemem does NOT display device driver information loaded under
     DOS version 4.xx or higher's "secondary" MCB's, although it will
     display such primary MCB's other software may use to load such
     device driver's "high" in UMB's if each is given its own MCB.
     This was a design decision to avoid "clutter."  Plenty of
     programs are available to "walk" the device chain and display
     this information.

     A word about resident code names is in order. Under DOS 2.xx the
     name of resident code is not determinable.  With DOS 3.xx the
     name may be determined from the environment, unless that was
     released back to DOS's pool on installation.  With DOS 4.xx and
     higher an eight character name is inserted in the last eight
     bytes of the 16 byte MCB, and therefore is always available.
     Some other programs which control UMB's insert the eight
     character name in the MCB under any DOS version, but this is not
     used by SEEMEM.  SEEMEM uses the most detailed information
     available.  Therefore, if the DOS version is 4 or higher, and the
     environment pertaining to the process is still resident, the
     program name and extension is taken from the environment
     (although the drive and directory information is stripped from
     the filename before display).

     A full explanation of the XMS and UMB, and HMA standards is not
     within the scope of this documentation, however an understanding

     of a few of the more obscure facts will help understand SEEMEM's
     operation.   The "XMS Specification" for extended memory is
     similar to the EMS spec for expanded memory.  It provides
     functions for implementing use of extended memory with handles in
     a manner very much the same as EMS does for expanded memory.  The
     High Memory Area (HMA) is the 64 kilobyte (less 16 bytes) just
     above the 1 megabyte limit of the 8086 and 8088 chips.
     Obviously, then XMS extended memory and the HMA require a '286
     chip or higher.  However, through a clever addressing scheme, and
     an additional hardware address line, an 80286 or higher can
     address the HMA in "real" mode, i.e. as "non-extended" memory.
     Although XMS drivers before DOS 5.00, and some alternative DOS-
     like operating systems allowed the use of this space for some
     things, DOS 5.00 now allows DOS itself to be loaded there,
     substantially increasing the possible useable memory space in
     lower memory previously used by DOS.

     Although the protocols and specifications for Upper Memory Blocks
     (UMB's) are contained in the original XMS specifications, they
     are NOT necessarily part of the XMS driver itself, and in fact
     were not implemented by the first MicroSoft driver, HIMEM.SYS.
     The XMS specification only provides one control vector however,
     so if all UMB calls need be implemented through that vector, a
     UMB driver must be integrated with the XMS driver, or must hook
     that vector (necessarily implying that it must be loaded after
     the XMS driver has installed the vector) unless it is completely
     integrated.  However DOS 5.00 has supplied interrupt 21h function
     calls to manipulate the use of existing UMB's for detecting the
     existence, state and governing the rules of use of UMB's, and
     these function calls are not dependent on the existence of any
     device driver, nor for that matter, the existence of any extended
     memory, or a chip higher than that 8088-8086.  The thought may
     take some getting used to, but this means that UMB's can exist
     without any driver or control vector at all.  In fact there is at
     least one program available which acts as though it were a device
     driver, creates UMB's from Chips and Technologies shadow ram,
     hands it over to DOS, and then just aborts, itself disappearing
     from memory.  DOS then owns, and makes available, some UMB's with
     no device driver to control them.  SEEMEM can even detect this
     type of UMB and display its state.

     DOS 5.00 provides greatly increased support for XMS, HMA, and
     UMB's, and SEEMEM uses all of it, where it is possible to do so.

     In order that it may support full display redirection SEEMEM does
     not do any direct video memory-mapped display.  All display is
     through DOS or BIOS.  Each screen is paged with a "MORE" line at
     the bottom UNLESS the /N ("NO PAUSE") switch is used.  The only
     other switch available is the help /H or /? switch, which
     displays a simple help message.  The output may be directed to a
     file or a device such as a printer, in which case you will
     probably wish to bypass paging also, with the /n switch.

     For example SEEMEM /N > PRN  would send the output of the program
     to the printer for a permanent record.  In order to speed the
     output slightly the DOS IOCTL function is used to switch to "raw"

     output mode, and is returned to its prior state, probably
     "cooked" upon program termination.  This speeds up output by
     eliminating checks for ^S, ^Q, ^C and expansion of tabs, etc., so
     you cannot manually pause the program or "break" it.  No tabs or
     other characters requiring interpretation are used however, so
     you should see no difference due to disallowance of "cooked"
     mode.

     If you insist on a "scrollable" output I have successfully used
     the J.P. Software's 4DOS command shell internal LIST command with
     SEEMEM to provide this with the following command line:

       SEEMEM /N | LIST

     This provides an output which uses LIST to scroll from top to
     bottom.

     This version (1.00B) of SEEMEM must be considered a beta version.
     Although it is believed to operate as described, I simply do not
     have a sufficiently diverse group of computers to test it on to
     determine that such a hardware specific program will work
     properly with all hardware configurations.  Thus no warranties or
     guarantees of any kind are made.

     I have made the source code available in Turbo Pascal 6.0 on the
     Borland Support area on GEnie and in the Borland Programming A
     area in CompuServe as SEEMTP.ZIP.  The program is copyright but
     donated to the public domain without any restriction, except
     that it be distributed in its original form with appropriate
     authorship credit, with no charge other than reasonable fees for
     duplication and distribution, including by electronic means.  It
     is specifically intended and permission is granted for
     distribution by commercial electronic sources for their regular
     and customary access and membership fees even though they may be
     operated for profit.

     The basic idea for SEEMEM is not new, of course and all
     parts of it borrow heavily upon prior, similar programs.  Perhaps
     it should be named YAMEM (Yet Another MEMory display program).
     Nevertheless it does do some things no other does (that I know
     of) and it is a demonstration of Turbo Pascal 6's BASM facility
     which clearly shows the practicality of the TP environment for
     low level system programming.  In fact, I don't think the same
     thing could be done in C with faster or smaller code resulting.
     Yeah, I know, TP is primarily a shell for the assembly stuff, but
     at least it can do that now, and very adroitly, too.

     I am considering writing a comprehensive XMS, UMB, and HMA Turbo
     Pascal Unit to implement the services supplied by device drivers
     under the XMS-UMB specification, which would also implement the
     new DOS 5.00 services connected to these facilities.  I would be
     interested in hearing from those who might want or need such a
     unit.  Of course, feedback on the use of SEEMEM would be
     appreciated, and I will be glad to provide help through E-Mail at
     the above addresses, or through the post, but I am not in a
     position to provide any real-time telephone support.

                          Rick Housh